先補上第四週的小結，再回頭看這 30 天。
| Day | 主題 | 一句話 |
|---|---|---|
| 22 | 擊穿與雪崩 | 熱門的 key 一過期，50 個人一起去查 DB，加了互斥鎖只剩 1 個人查；TTL 加隨機秒數防雪崩 |
| 23 | 快取一致性 | 先改 DB 再刪快取，快取還是會有一小段時間跟 DB 不一樣 |
| 24 | 分散式鎖 | 過期時間一起設、刪之前確認是自己的，做太久交給看門狗 |
| 25 | 秒殺：重現超賣 | 先讀再寫，100 件賣出 2308 件；改用 Lua 扣，剛好 100 件 |
| 26 | 秒殺：限流與削峰 | 門口先擋掉多的，搶到的排隊慢慢寫 DB |
| 27 | 大 Key 與熱 Key | 刪 100 萬筆的大 Key 卡了 88 毫秒；熱 Key 讀多就 App 自己存一份，寫多就拆成好幾個 key |
| 28 | 監控與調校 | 命中率、連線數、記憶體碎片，INFO 都看得到；常用 MULTI、Pipeline 就加連線池，碎片多就開 activedefrag |
| 29 | 分散式鎖的極限 | 主節點換手的時候，兩個人可能拿到同一把鎖 |
Day 22–23 是快取，Day 24–26 是很多人搶同一個東西，Day 27–28 是上線之後要顧的，Day 29 回頭看 Redis 出事的時候鎖還靠不靠得住。
| 主題 | Day | 在處理什麼 |
|---|---|---|
| 資料型別 | 4–10 | 東西要用哪種型別放 |
| 內部機制 | 3、11–13 | 為什麼快、資料一大就換結構、過期的 key 什麼時候刪、記憶體滿了怎麼辦 |
| 持久化、主從與叢集 | 14–18 | 資料不要掉、機器掛了有人接、一台不夠用 |
| 指令一起做 | 19–20 | 省來回、中間不被插隊 |
| 快取 | 21–23 | 查不存在的、熱門的剛好過期、一大批同時過期、跟 DB 對不上 |
| 併發與秒殺 | 24–26、29 | 很多人同時搶同一個東西、Redis 出事的時候鎖還靠不靠得住 |
| 上線之後 | 27–28 | 找出拖慢的 key、看懂 INFO、加連線池、整理記憶體碎片 |
不知不覺到了最後一天了，其實每天學一點新知識真的不錯，有種踏實的感覺。
從最初只知道 Redis 是拿來做快取，到後期越了解就越佩服，在還沒有 AI 幫忙寫程式的年代，就已經有人做出這麼複雜的東西。
透過這次鐵人賽讓我對 Redis 有更深入的了解，這也是我第一次堅持 30 天學習一項技術。
期許自己能夠保持這個精神，持續學習更多新知。
謝謝一路看到這裡的大家
iThome鐵人賽
看影片追技術